大家好！昨天我們成功施展了容器化魔法，把 ADK 代理人打包成乾淨的 Docker Image。今天，我們要貫徹「雲端先決」的策略，將這個容器正式部署到 Google Cloud Run。

揮別金鑰焦慮：Cloud Run 的零維運魔法
傳統部署最讓人頭痛的就是管理憑證檔案。但在我們精心設計的架構中，當部署到 Google Cloud 的代管環境（例如 Agent Runtime、Cloud Run 或 GKE）時，該環境會自動提供所需的憑證。

• 免除配置：在這些代管環境中，完全不需要進行金鑰檔案的設定與管理。

• 極致安全：徹底杜絕了 .env 或 .json 金鑰外洩的資安風險，將「研發與工程創新」的安全標準拉到最高。

升空前的關鍵改裝：避開常見的部署陷阱
在上雲之前，我們需要對 Dockerfile 進行確認與關鍵微調，並注意本機環境的晶片架構，否則很容易在 Cloud Run 上遭遇連線重設或啟動失敗：

• 1 破除內部迴圈魔咒 (0.0.0.0)：ADK 伺服器預設只監聽容器內部的 127.0.0.1。我們必須在 Dockerfile 的啟動指令加上 --host 0.0.0.0，才能讓 Cloud Run 順利將外部流量導入。

• 2 綁定正確的 Port：明確宣告並監聽 8000 or 8080 通訊埠。(如有修改Port的例子)

# Dockerfile 底部請修改為：
EXPOSE 8000 / 8080
CMD ["adk", "web", "--host", "0.0.0.0", "--port", "8000 / 8080"]

• 3 突破 Apple Silicon 架構限制：如果你使用 Mac M 系列晶片 (ARM64)，請務必在打包時強制指定為 Cloud Run 支援的 amd64 架構，否則部署後會跳出晶片不相容的錯誤。

# 加上 platform 參數進行跨架構編譯
docker build --platform linux/amd64 -t my-adk-web-room .

第一步：建立雲端軍火庫 (Artifact Registry)
要將本地端的 Docker Image 送上 Google Cloud，我們必須先在雲端建立一個專屬的 Docker 儲存區。請確保你的終端機已經登入 gcloud，並將預設專案設定為我們的實戰專案：

gcloud auth login
gcloud config set project "your project id"

接著，在台灣機房 (asia-east1) 建立一個名為 adk-repo 的 Artifact Registry：

gcloud artifacts repositories create adk-repo \
    --repository-format=docker \
    --location=asia-east1

第二步：真實戰場的成年禮——打通 Docker 雲端權限
在實戰部署時，很多開發者把 Image 打好標籤準備 docker push 時，往往會迎來無情的紅色錯誤訊息：
Unauthenticated request. Unauthenticated requests do not have permission...

這是一個非常經典的「雲端陷阱」！因為你的本地端 Docker 尚未取得登入 Google Artifact Registry (GAR) 的授權。為了解決這個問題，我們必須執行以下指令，將 Docker 的認證機制與 gcloud 綁定：

gcloud auth configure-docker asia-east1-docker.pkg.dev

當你看到設定成功寫入 .docker/config.json，就代表 Docker 已經取得了 Google Cloud 的雲端通關密語！

現在，我們可以放心地為 Image 貼上雲端標籤，並正式發射升空：

# 1. 打上 GAR 專屬標籤
docker tag my-adk-web-room asia-east1-docker.pkg.dev/your_porject_id/adk-repo/my-adk-web-room:latest

# 2. 推送上雲端
docker push asia-east1-docker.pkg.dev/your_porject_id/adk-repo/my-adk-web-room:latest

第三步：Cloud Run 的無金鑰魔法部署當 Image 成功推上雲端後，我們只要一行指令就能讓 Cloud Run 接手剩下的所有苦差事。在架構設計上，當我們將 ADK 代理人部署到 Google Cloud 的代管環境（例如 Agent Runtime、Cloud Run 或 GKE）時，該環境會自動提供所需的認證憑證，完全不需要進行任何金鑰檔案的配置與管理。這徹底杜絕了金鑰外洩的資安風險！只需要一行指令(port 8000 為例) 讓我們見證這個魔法：

gcloud run deploy adk-web-room \
    --image asia-east1-docker.pkg.dev/YOUR_PROJECT_ID/adk-repo/my-adk-web-room:latest \
    --region asia-east1 \
    --port 8000 \  
    --allow-unauthenticated \
    --set-env-vars GOOGLE_GENAI_USE_ENTERPRISE=TRUE,GOOGLE_CLOUD_PROJECT=YOUR_PROJECT_ID,GOOGLE_CLOUD_LOCATION=us-central1

注意： 加上 GOOGLE_GENAI_USE_ENTERPRISE=TRUE 代表我們正式切換為 Vertex AI 企業級模型，享受更進階的雲端算力與資安防護！

部署完成後，終端機會回傳一串專屬的 HTTPS 網址。這意味著你的團隊成員再也不用在本地端裝環境，只要點開網址就能立刻測試 AI 代理人的火力！

戰略反思：這是真正的 Production 嗎？
看著在雲端穩定運作的戰情室，我們還是要保持軟體工程師的理性。

- 非正式環境：官方嚴正提醒，ADK Web 介面並不建議直接用於正式的生產環境部署。

- 除錯專用：你應該僅將 ADK Web 介面用於開發與除錯用途。

這也是為什麼我們把它定位為內部的「戰情室 Prototype」。在後續的挑戰中，我們會進一步探討如何為代理人建立企業級的 API Server。

小結
恭喜大家！我們不但成功排除了權限卡關的真實痛點，還將 ADK 代理人推向雲端，實踐了無金鑰的安全部署架構。Cloud Run 自動擴充的特性，確保了未來即使面對高流量，系統也能穩如泰山。